This application relates to graphics processing, and in some example embodiments, more specifically relates to efficiently rendering Bezier curves.
Complex curves, such as quadratic Bezier curves are the basic building blocks of many applications, such as various vector graphics applications (e.g., Adobe Flash™), and may be used to represent glyph outlines in various different font standards (e.g., TrueType).
Some more graphic-intensive applications (e.g., Illustrator®) may stroke cubic Beziers by approximating them to lower order Quadratic Bezier curves or straight lines and then rendering the approximated Quadratic Bezier curves or straight lines. Stroking a complex curve (e.g., quadratic Bezier curve) is fundamentally a computationally time consuming and intensive operation. Even when executed on a graphics processing unit (GPU), such a stroking task can be very slow, as most current techniques employ central processing unit (CPU) for lower order approximation and tessellation of a control shape bounding the approximation into tiles, and then offload the rendering operation using the tiles to the GPU. This partial CPU involvement often makes the stroking process resolution-dependent. Every time the resolution changes, the CPU has to re-tessellate the Bezier curve control shape and then again offload the rendering to GPU.
One solution, which discusses approaches for resolution-independent curve rendering using programmable graphics hardware (hereinafter Loop-Blinn), attempts to address the problem of requiring the CPU to re-determine and tessellate the control shape using a resolution-independent technique that does not require CPU tessellation. In particular, Loop-Blinn describes a process that computes a set of texture coordinates defining a control triangle that corresponds to the control points of a Bezier curved line, and evaluating the texture coordinates using a pixel shader to determine if corresponding pixels are inside or outside the curved line. However, the solution described by Loop-Blinn, in its current form, suffers from at least the problem of having to process too many fragments in order to render the curved lines (referred to as over-coverage), and thus has proven to be too slow for practical use. Further, this solution often fails to resolve the ends of the curved lines proximate the control points sufficiently (referred to as under-coverage).
Another problem with existing Bezier-based solutions is that they are generally unable to handle thin strokes, such as strokes having a width less than one pixel especially at low-resolution levels. These solutions attempt to address this deficiency by using separate processing logic for rendering a stroke when it is thin (e.g., using prefiltered lines) as compared to when the line is not thin, which disadvantageously makes the implementation resolution dependent.